An application program interface (API) for a network platform can be used by developers to build Web applications and services. One such API is the .NET™ platform created by Microsoft Corporation of Redmond, Wash., USA. The .NET™ platform is a software platform for Web services and Web applications implemented in a distributed computing environment. The .Net framework is not only intended for web services and application development, but is also intended as a general programming platform that enables both web services and application development as well as rich client application development. The .NET™ platform allows integration of a wide range of services that can be tailored to the needs of the user. As used herein, the phrase application program interface or API includes traditional interfaces that employ method or function calls, as well as remote calls (e.g., a proxy, stub relationship) and SOAP/XML invocations. The .NET™ platform uses a framework that includes a Common Language Runtime (CLR). Additional information regarding the basics of the .NET™ Framework can be found in a number of introductory texts, such as Pratt, Introducing Microsoft .NET, Third Edition, Microsoft Press, 2003.
The CLR is the heart of the Microsoft .NET™ Framework and provides the execution environment for all .NET code. Thus, code that is built to make use of the CLR, and that runs within the CLR, is referred to as “managed code.” The CLR provides various functions and services required for program execution, including ‘Just-In-Time’ (JIT) compilation, allocating and managing memory, enforcing type safety, exception handling, thread management and security. The CLR is loaded upon the first invocation of a .NET™ routine. Because managed code is JIT compiled to native code prior to execution, significant performance increases can be realized in some scenarios. Managed code uses Code Access Security (CAS) to prevent assemblies from performing certain operations that could represent a security violation.
When writing managed code, the deployment unit is called an assembly which is a collection of one or more files that are versioned and deployed as a unit. An assembly is the primary building block of a .NET™ Framework application. All managed types and resources are contained within an assembly and are marked either as accessible only within the assembly or as accessible from code in other assemblies. An assembly is packaged as a data link library (DLL) file or executable (EXE) file. While an executable can run on its own, a DLL must be hosted in an existing application.
One or more methods in an assembly may call to access protected resources associated with another method. This call can be a cross assembly call (e.g., a call to a different assembly), or the call can be a call from one method to another within the same assembly. Various permissions can be requested by a method that contains security relevant resources, and various permissions can be assigned to each method. The assembly that contains the caller method must have been granted the required permissions before access is provided to the protected security relevant resources. Otherwise, a security exception will be triggered.
As a developer develops an application that will run in a managed environment, the application can be successively executed in order to find out if the application's source code has been written so that it will operate correctly in the targeted security context Alternatively, a manual review of every line of code in the application being developed can be made to try to find the security requirements associated with the calls that would be made during an actual execution of the application. Then, the results of the manual review can be summarized as to the security requirements for its execution. This summary can then be compared to a maximum level of security that the developer may not exceed for the application being developed.
Of course, both the try-and-error execution technique and the manual review technique can be time consuming and impractical to perform, as knowledge of the code in assemblies not written by the developer is required, i.e., a security check might be triggered by a shared managed library that the developer uses in order to implement a feature. It would be an advance in the art to provide an efficient technique to derive what the minimum security requirements are for executing managed code prior to a deployment of the managed code, prior to a release of the managed code, and/or prior to an actual execution of the managed code.